Relaxing constraints in stateful network data plane design

Modern network devices have to meet stringent performance requirements while providing support for a growing number of use cases and applications. In such a context, a programmable network data plane has emerged as an important feature of modern forwarding elements, such as switches and network cards. Bosshart et al. [1] introduced RMT, a first example of a high-performance programmable data plane. RMT provides a reconfigurable switching ASIC that can parse and modify arbitrary packet headers in a pipeline of match-action tables (MAT). Interestingly, [1] shows that such programmability can be supported with performance comparable to state-of-the-art fixed-function chips: it can process packets at a line rate of 640 Gb/s. More recently, Sivaraman et al. [2] presented an abstraction for a switching ASIC, named Banzai, which supports the programming of stateful packet processing functions. The statefullness lays in the ability to create and modify state while processing a packet, enabling the definition of functions that depend on the history of previously received packets. Such functions enable complex applications such as stateful firewalls, active queue management, scheduling, monitoring, etc. Banzai extends RMT’s MATs by adding stateful actions, named “atoms”. Each atom, as the name suggests, performs state operations atomically. The atomicity is required to guarantee consistency, i.e., read and write operations to an atom’s memory area cannot be performed by different packets at the same time. In effect, Banzai requires the serial processing of all the packets. This model is convenient since a forwarding element’s data plane is already processing packets in a serial manner. However, to meet a given performance target, the serial processing model requires the definition of a strict time budget for the processing of each packet. For instance, in the case of RMT, the switching ASIC is dimensioned to process 640 Gb/s with minimum size Ethernet packets (64 bytes), which translates to a time budget of 1 ns per packet1. Likewise, the chip clock frequency is dimensioned according to the desired target throughput. In the previous case, a 1 Ghz clock is used to provide the 640 Gb/s. The final outcome is that each atom has to perform state read, modification and write operations in at most 1 ns, i.e., 1 clock cycle. Unfortunately, while providing line rate guarantees, Banzai fails to implement more complex functions that require atoms that cannot be executed in the available time budget.